Lambdaのログレベル方針について、チームで話して明文化してみた

Lambdaを実装しているとき、ふと「ログのレベルって決めてたっけ？」となりました。 個人の基準はあってもチームとしては曖昧だったので（開発者のさじ加減）、チームで話し合って明文化してみました。

前提

• 対象はLambdaのログです
• ERRORレベルのログがあるとき、Slackに通知する仕組みがあります
• この通知を元に開発者が確認を行い、必要に応じて対処します
• AWSの環境は3つです
• development
• staging
• production

ログを残す理由

• Lambdaの処理で何かあったことを認識するため
• 何らかの対応（暫定・恒久）を行うとき、参考情報とするため

CloudWatch AlarmでLambdaのエラー監視をすればLambdaの実行が失敗したことは分かりますが、適切なログが無ければ、「何をしようとして失敗したのか？」「その時のパラメータは何か？」などが分かりません。

また、不具合の暫定対応や恒久対応を行うにしても、適切なログが無ければ「そもそも何をすれば良いの？」「効果検証はどうするの？」となってしまいます。

ログレベルのポリシーを決めた

レベル	概要
ERROR	Slack通知したい情報（対処が必要な事象が起きた）
WARNING	Slack通知しないが、残したい情報（対処は不要だけど気にしておきたい）
INFO	開発者がLambdaの処理を追うのに必要な情報（対処する際の参考情報）
DEBUG	開発時にあると嬉しい情報

ERROR

• Slack通知したい情報（対処が必要な事象が起きた）

具体的には下記です。

• Lambdaが落ちた
• デプロイパッケージに必要なライブラリが無かった
• コードをtypoしてた
• など
• DynamoDBからデータ取得しようとしたけど失敗し、処理続行できなかった
• 想定外のデータがあり処理続行できなかった
• など

ただし、API Gatewayの裏側にいるLambdaの場合、API利用者から見て400系の場合は意図的にエラーログを出さないようにします（クライアント要因のエラーをSlackに通知しても、開発者がやることは無いため）。

• 400：API Request Bodyの値が想定外である
• 404：存在しないIDに対するReadアクセス
• など

WARNING

• ノイズになるのでSlack通知しないが、残したい情報（対処は不要だけど気にしておきたい）
• エラーが発生したが、期待通りの動作が行われた

具体的には下記です。

• DynamoDBからデータ取得に失敗したが、リトライ処理では成功した
• 必須データが無いけど、デフォルト値を使って処理を続行した
• など

INFO

• 開発者がLambdaの処理を追うのに必要な情報（対処する際の参考情報）

具体的には下記です。

• Lambdaの入口(event, 環境変数)
• Lambdaの出口(処理の結果)
• Lambda以外に関するアクセスやデータ(DynamoDB・S3・IoTなど)
• Requestの内容
• Responseの内容

DEBUG

• 開発時にあると嬉しい情報

具体的には下記です。DEBUGレベルのログは、development環境のみで出力させます。

• 関数の出入り
• 特定変数の内容
• など

頭の隅に置いておくこと

ログが多すぎると料金が高くなる

なんでもかんでもログ出力すると、CloudWatch Logsの料金が地味に高くなります。 CloudWatch Logsは、ログの取込料金が0.76USD/GBです。 もし、「とりあえずログに残しとくか」というログが1日1GBあるなら、30日で約23USDです。

さいごに

私のいるチームでは上記のようになりました。ログに何を求めているか、そしてログレベルはどうするのか、これらはチーム毎に異なると思います（ERRORとWARNINGはビジネスに与える影響を考慮するなど）。 改めて話し合ってみると良さそうですね。

参考

• 料金 - Amazon CloudWatch | AWS
• 【小ネタ】CloudWatch Logsの料金が高かったのでAWS CLIを使って調査した話 | Developers.IO